JCapper Message Board

          JCapper 101
                      -- Horses not showing up in Individual Plays in Data Window when running UDM

"I use FormRating in most of my UDMs (and likely always will.)

That said, I need to make it clear that FormRating is unlike the other ratings in the program in that it contains a random component that - every once in a while - is going to be different on race day when the Calc Races button is clicked vs. what gets persisted when the Build Database button is clicked.

It's a behavior that has always bothered me - and at the same time - it's something I have never been able to solve.

Over the years I've had to learn to live with.

---

I posted about the behavior of FormRating at length on the old/original JCapper Message Board (if I recall correctly) as far back as 2005.

That said, the old/original JCapper Message Board is no longer accesible.

Using THIS message board's search link - I came up with a thread from 2008.

In the second post down from the top I described the random part of FormRating along with the scenario that sometimes causes it to change from the point in time when the html report is run to when the Data Window is later run:
http://www.jcapper.com/MessageBoard/TopicReader.asp?topic=276&forum=Private

---

--quote:

"FormRating - This number represents a horse's current form relative to the rest of the field. Horses with improved performances in recent races and workouts are awarded points while horses with declining performances in recent races and workouts receive point deductions. Benchmark testing of the FormRating has revealed the following: horses ranked highly in FormRating substantially outperformed horses ranked poorly in FormRating, both in terms of win rate and money returned.

Note: The original FormRating in JCapper is based in part on an element that simulates random improvement or decline. Much has been posted about this on the JCapper Message Board. Because of the way random numbers are referenced in Visual Basic, other programs running outside of JCapper have the ability to overwrite the area in memory where random numbers are stored. In a small percentage of cases, this casues the FormRating to be a moving target and tough to nail down when comparing the FormRating shown on the HTML Report and later in the Data Window after a Build Database has been run. I have tried to the best of my ability to address this issue but as of this writing a true solution has evaded me. During all of my tests, a JRating using a FormRating containing this random element always outperforms a JRating based on a FormRating without this random element. For that reason alone I have left JCapper's original JRating and FormRating intact. (Accessible via the Profile Table Interface)

AFR - or Advanced Form Rating - This number represents a horse's current form relative to the rest of the field. Horses with improved performances in recent races and workouts are awarded points while horses with declining performances in recent races and workouts receive point deductions. Becnhmark testing of the FormRating has revealed the following: horses ranked highly in AFR substantially outperformed horses ranked poorly in AFR, both in terms of win rate and money returned.

Note: AFR (or Advanced FormRating) is an improvement over JCapper's original FormRating. AFR uses a slightly different factor set than FormRating. AFR is a "hard" rating that doesn't use a random element. I've included it in JCapper's factor set and made it one of the "grab-able" factors so that those of you who wish to use it in UDMs and in the factor mix of your own User Defined Power Ratings can do so. In benchmark tests, AFR does a better job of predicting the outcome and has a higher flat bet win roi than the program's original FormRating does.
(Accessible via the Profile Table Interface)"

--end quote

---

The above quoted text provides background info into what's happening behind the scenes.

I'll try to provide a little more depth below:

One of the things that gives FormRating the ability to add roi to a UDM is the part of its makeup that is based on a random number.

My intent on adding a random component to FormRating was to simulate the sometimes random swings (good race one time vs. bad race next time) seen in the performances/running lines of individual horses.

Will he run a good race today? Or will he run a clunker?

No matter how strongly everything looks like it lines up there's always a pct chance that performance today differs greatly from what we expect.

About 90% plus of FormRating is hard coded and never varies.

The remainder is based on random numbers representing different aspects of improvement or decline. These random components are generated on the fly. The algorithm I created writes these random numbers to a specific area in ram memory that's supposed to be reserved for VB.

Most of the time everything works as designed and horses flagged on the html report by UDMs using FormRating are the same as those seen later in the Data Window. (My testing reveals that when this is the case the area in VB where the random components of FormRating are being stored remains untouched by other apps running on the machine.)

But every once in a while the area in memory where the random components of FormRating are being stored get overwritten by another app running on the machine - or become corrupted by some other cause.

When this happens the random number elements going to FormRating change - and FormRating changes right along with them - and the resulting change in FormRating can cause the scenario I think you are describing.

It's a "bug" I was never fully able to solve.

My first "solution" - if you can call it that - was to create a new form rating factor called AFR - one that does not contain a random element.

Because AFR does not contain a random element, if you use AFR in a UDM instead of FormRating - horses flagged by the UDM on an html report should always be the same as those seen in the Data Window... barring scratches or other changes within the same race.

---

My next attempt at a "solution" - again if you can call it that - was to add the UPR and JPR Gap Rev buttons on the User System Definitions Screen.

Hint: The settings persisted on my own User Sys Defs Screen are shown at the top of the Help Doc: Here.

Note that I am using my own UPR GroupName to drive UPR and that I have the UPR Gap Rev box checked. I recommend you do the same. Checking the box causes the random components of FormRating to be handled in a slightly different way. This does not eliminate the possibility of the area where they are stored in ram memory to be overwritten during a build db routine - but it does cut down on the incidence rate.

If you are using a UPR GroupName to drive UPR check the UPR Gap Rev Box. If you aren't - consider checking the JPR Gap Rev Box.

Important: After checking either box, you'll want to rebuild databases from scratch and look at your numbers in the Data Window - and note any changes in UDM performance that result from checking the box(es.)

---

Wrapping Up
Despite the fact that the random components of FormRating sometimes get overwritten in memory during a database build - I find that my own long term results from live play are better when I include FormRating in my UDMs vs. not using FormRating in my UDMs."